home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 1999 August / SGI Freeware 1999 August.iso / dist / fw_amanda.idb / usr / freeware / doc / amanda / FAQ.z / FAQ
Encoding:
Text File  |  1999-07-16  |  21.8 KB  |  481 lines

  1. This file contains answers to some questions that are frequently asked
  2. in the Amanda mailing lists, specially by new users.  Please take a
  3. look at this file before posting, this can save us time that could be
  4. spent improving Amanda and its documentation.
  5.  
  6. New entries and modifications are welcome; send them to
  7. amanda-users@amanda.org or amanda-hackers@amanda.org.
  8.  
  9. You may also want to take a look at Oren Teich's Amanda FAQ Page,
  10. http://ugrad-www.cs.colorado.edu/~teich/amanda
  11.  
  12. He is no longer maintaining that page, but it still contains useful
  13. and accurate information.
  14.  
  15.  
  16. Q: Why does Amanda fail to build on my system?
  17.  
  18. A: One of the most common reasons for compile-time errors is stale
  19. information in `config.cache', after a build on a different platform
  20. using the same build tree.  In order to avoid this problem, make sure
  21. you don't ever reuse build trees across platforms, or at least run
  22. `make distclean' before running `configure' on another platform.
  23.  
  24.    Another common reason for failure, that causes link-time errors, is
  25. a problem in libtool that causes it to search for symbols in
  26. already-installed amanda libraries, instead of in the just-built ones.
  27. This problem is known to affect SunOS 4.1.3 and FreeBSD.  You can
  28. usually work around it by specifying a different prefix when you
  29. configure the new version of Amanda.  However, it may not work if the
  30. previous version of Amanda was installed in /usr/local and gcc
  31. searches this directory by default; in this case, you must either
  32. remove the old libraries (which you don't want to do, right? :-) or
  33. call configure with the flag --disable-libtool.  In this case, Amanda
  34. won't create shared libraries, so binaries will be larger, but you may
  35. worry about that later.
  36.  
  37.    You may also want to take a look at docs/SYSTEM.NOTES, as well as
  38. to the Amanda Patches Page (check www.amanda.org) for other known
  39. problems.  If everything fails, you should read the manual, but since
  40. we don't have one yet, just post a help request to the amanda-users
  41. mailing list, showing the last few lines of the failed build.
  42.  
  43.  
  44. Q: Why does `amdump' report that all disks failed?
  45.  
  46. A: Probably because the Amanda clients are not properly configured.
  47. Before you ever run `amdump', make sure `amcheck' succeeds.  When it
  48. does, so should `amdump'.
  49.  
  50.    Make sure you run `amcheck' as the same user that is supposed to
  51. start `amdump', otherwise you may get incorrect results.
  52.  
  53.  
  54. Q: Why does `amcheck' say `port NNN is not secure'?
  55.  
  56. A: Because `amcheck', as some other Amanda programs, must be installed
  57. as setuid-root.  Run `make install' as `root', or `chown' all Amanda
  58. setuid programs to `root', then `chmod u+s' them again, if `chown'
  59. drops the setuid bit.
  60.  
  61.  
  62. Q: Why does `amcheck' claim that the tape is `not an amanda tape'?
  63.  
  64. A: Because Amanda requires you to label tapes before it uses them.
  65. Run `amlabel' in order to label a tape.
  66.  
  67.    If, even after labeling a tape, `amcheck' still complains about it,
  68. make sure the regular expression specified in amanda.conf matches the
  69. label you have specified, and check whether you have configured
  70. non-rewinding tape devices for Amanda to use.  For example, use
  71. /dev/nrst0 instead of /dev/rst0, /dev/rmt/0bn instead of /dev/rmt/0b,
  72. or some other system-dependent device name that contains an `n',
  73. instead of one that does not.  The `n' stands for non-rewinding.
  74.  
  75.    If you have labeled any tapes using the rewiding device
  76. configuration, you'll have to label them again.
  77.  
  78.  
  79. Q: Why does `amcheck' report `selfcheck timed out'?
  80.  
  81. A: This can occur under several different situations.  First, make
  82. sure this problem is repeatable; if Amanda programs are
  83. NFS-auto-mounted, some clients may fail to mount the Amanda binaries
  84. in time.
  85.  
  86.    If the error is repeatable, log into the client, and check whether
  87. the directory /tmp/amanda exists, and a file named amandad.debug
  88. exists in there: amandad will create this file whenever it starts.  If
  89. this file does not exist, amandad is not starting properly, or it
  90. lacks permission to create /tmp/amanda/amandad.debug.
  91.  
  92.    In the latter case, wipe out /tmp/amanda, and amandad should create
  93. it next time it runs.  In the former case, check your inetd
  94. configuration.  Make sure you have added the Amanda services to
  95. /etc/services, that /etc/inetd.conf was properly configured, and that
  96. you have signalled inetd to reread this file.  Check section 2.2 from
  97. the INSTALL file for details.
  98.  
  99.    Pay special attention to typos in inetd.conf; error messages will
  100. probably appear in /var/adm/messages if you have typed the amandad
  101. program name incorrectly.  Make sure the same user that you have
  102. specified at configure-time (--with-user=<USERNAME>) is listed in
  103. inetd.conf.  Check whether this user has permission to run amandad, as
  104. well as any shared libraries amandad depends upon, by running the
  105. specified amandad command by hand, as the Amanda user.  If you type
  106. anything, amandad should abort because it can't read a UDP packet
  107. from the keyboard.
  108.  
  109.    As soon as you have properly configured inetd.conf so as to run
  110. amandad, you should no longer get the `selfcheck timed out' message.
  111.  
  112.  
  113. Q: Why does `amandad.debug' contain `error receiving message'?
  114.  
  115. A: One possibility is that you have run `amandad' from the command
  116. line prompt and typed anything instead of waiting for it to time-out:
  117. in this case, it will try to read a UDP packet from the keyboard, and
  118. this was reported not to work on most keyboards :-).  However, if you
  119. have run `amandad' as any user other than the one listed in
  120. `inetd.conf', it may have created a /tmp/amanda directory that the
  121. Amanda user cannot write to, so you should wipe it out.
  122.  
  123.    Another possibility is that the Amanda service was not properly
  124. configured as a UDP service; check /etc/services and /etc/inetd.conf.
  125.  
  126.  
  127. Q: Why does `amcheck' say `access as <username> not allowed...'
  128.  
  129. A: There must be something wrong with .amandahosts configuration (or
  130. .rhosts, if you have not configured --with-amandahosts).
  131.  
  132.    First, if the <username> is not what you expect (i.e., not what you
  133. have specified in the --with-user flag, at configure time), check the
  134. inetd configuration file: you must have specified the wrong username
  135. there.
  136.  
  137.    Make sure you specify a fully-qualified domain name in
  138. .amandahosts/.rhosts; aliases are better avoided, for security
  139. reasons.
  140.  
  141.  
  142. Q: Why does `amcheck' report `ip address #.#.#.# is not in the ip list 
  143. list for <hostname>'?
  144.  
  145. A: Check your DNS configuration tables.  In order to avoid
  146. DNS-spoofing, Amanda double-checks hostname<->IP address mapping.  If
  147. the IP address the request comes from maps to a hostname, but this
  148. hostname does not map back to the incoming IP address, the request is
  149. denied.
  150.  
  151.  
  152. Q: Why does `amcheck' say `cannot overwrite active tape'?
  153.  
  154. A: Because, if you configure Amanda to use N tapes, by setting
  155. tapecycle to N in `amanda.conf', before Amanda overwrites a tape, it
  156. must write to at least other N-1 tapes.  Of course, Amanda will always
  157. refuse to overwrite a tape marked for `noreuse' with `amadmin'.
  158. Furthermore, such tapes are not counted when Amanda computes `N-1'
  159. tapes.
  160.  
  161.    If, for some reason, you want to tell Amanda to overwrite a
  162. particular tape, regardless of its position in the cycle, use
  163. `amrmtape'.  This command will remove this tape from the `tapelist'
  164. file, that is used to manage the tape cycle, and will delete
  165. information about backups stored in that tape from the Amanda
  166. database.
  167.  
  168.  
  169. Q: Why does `amcheck' tell me `DUMP program not available'?
  170.  
  171. A: Because the `configure' could not find DUMP when it was first run.
  172. This is a common problem on Linux hosts, because most Linux
  173. distributions do not install DUMP by default.
  174.  
  175.    If you don't have a DUMP program installed, install it, remove
  176. `config.cache', run `configure' again and rebuild Amanda.  While
  177. `configure' is running, make sure it can find the installed DUMP
  178. program.  If it cannot, you may have to set the environment variables
  179. DUMP and RESTORE by hand, before running configure.
  180.  
  181.    If you can't or don't want to install DUMP, you may use GNU tar,
  182. but make sure it as release 1.12 or newer; release 1.11.8 may work,
  183. but estimates will be slow as hell.
  184.  
  185.  
  186. Q: Which tape changer configuration should I use in amanda.conf?
  187.  
  188. A: If you only have one tape unit, you have two choices: (i) don't use
  189. a tape changer at all, i.e., set runtapes to 1, set tapedev to the
  190. non-rewinding device corresponding to the tape unit, and comment out
  191. tpchanger, changerfile and changerdev; or (ii) set up chg-manual, so
  192. that you can change tapes manually.  If you select chg-manual, you
  193. will not be able to start `amdump' as a cron job, and you should
  194. always run `amflush -f', because chg-manual will ask you to press
  195. return in the terminal where you started the controlling program.
  196.  
  197.    If you have several tape units, which you want to use to emulate a
  198. tape changer, you want chg-multi.  Even if you do own a real tape
  199. changer, that operates based on ejecting a tape or such, chg-multi may
  200. be useful.
  201.  
  202.    Actual tape changers usually require specialized changer programs,
  203. such as `mtx', `chio' or specific system calls.  The availability of
  204. these programs is much more dependent on the operating system you're
  205. running than on the particular tape changer hardware you have.
  206.  
  207.    `mtx', for example, is available for several platforms.  However,
  208. even if you find it for your platform, beware that there exist several
  209. different programs named `mtx', that require different command line
  210. arguments, and print different output, and Amanda's chg-mtx does not
  211. support them all.  You may have to edit the script, which shouldn't be
  212. hard to do.
  213.  
  214.    In section BUILT-IN TAPE CHANGERS of docs/TAPE.CHANGERS, you will
  215. find details about the tape changer interfacing programs provided with
  216. Amanda, that can interact with common tape changer programs and with
  217. tape changer-related system calls provided by some operating system.
  218. If none of them matches your needs, you may have to develop your own
  219. tape changer interface script.
  220.  
  221.    Before posting a question to the Amanda mailing lists, *please*
  222. search the archives, and try to obtain as much information about
  223. driving your tape changer hardware from the vendor of the changer
  224. hardware and of the operating system, rather than from the Amanda
  225. mailing lists.  We usually don't have much to say about tape changer
  226. units, and several questions about them remain unanswered.  :-(
  227.  
  228.    Anyway, if you decide to post a question, make sure you specify
  229. both the tape changer hardware *and* the OS/platform that is going to
  230. interface with it.  Good luck! :-)
  231.  
  232.  
  233. Q: Should I use software or hardware compression?
  234.  
  235. A: When you enable software compression, you drastically reduce the
  236. compression that might be achieved by hardware.  In fact, tape drives
  237. will usually use *more* tape if you tell them to try to further
  238. compress already compressed data.
  239.  
  240.    Thus, you must choose whether you're going to use software or
  241. hardware compression; don't ever enable both unless you want to waste
  242. tape space.
  243.  
  244.    Since Amanda prefers to have complete information about tape sizes
  245. and compression rates, it can do a better job if you use software
  246. compression.  However, if you can't afford the extra CPU usage, Amanda
  247. can live with the unpredictability of hardware compression, but you'll
  248. have to be very conservative about the specified tape size, specially
  249. if there are filesystems that contain mostly uncompressible data.
  250.  
  251.  
  252. Q: How can I configure Amanda so that it performs full backups on the
  253. week-end and incrementals on weekdays?
  254.  
  255. A: You can't.  Amanda doesn't work this way.  You just have to tell
  256. Amanda how many tapes you have (tapecycle), and how often you want it
  257. to perform full backups of each filesystem (dumpcycle).  It will
  258. spread full backups along the dumpcycle, so you won't have any
  259. full-only or incremental-only runs.
  260.  
  261.  
  262. Q: What if my tape unit uses expensive tapes, and I don't want to use
  263. one tape per day?  Can't Amanda append to tapes?
  264.  
  265. A: It can't, and this is good.  Tape drives and OS drivers are
  266. (in)famous for rewinding tapes at unexpected times, without telling
  267. the program that's writing to them.  If you have a month's worth of
  268. backups in that tape, you really don't want them to be overwritten, so
  269. Amanda has taken the safe approach of requiring tapes to be written
  270. from the beginning on every run.
  271.  
  272.    This can be wasteful, specially if you have a small amount of data
  273. to back up, but expensive large-capacity tapes.  One possible approach
  274. is to run amdump with tapes only, say once a week, to perform full
  275. backups, and run it without tape on the other days, so that it
  276. performs incremental backups and stores them in the holding disk.
  277. Once or twice a week, you flush all backups in the holding disk to a
  278. single tape.
  279.  
  280.    If you don't trust your holding disk, and you'd rather have all
  281. your data on tapes daily, you can create an alternate configuration,
  282. with two tapes, that backs up the holding disk only, always as a full
  283. backup.  You'd run this configuration always after your regular
  284. backup, so you always have a complete image of the holding disk on
  285. tape, just in case it fails.
  286.  
  287.  
  288. Q: How can I configure Amanda for long-term archiving?
  289.  
  290. A: The best approach is to create a separate configuration for your
  291. archive backups.  It should use a separate set of tapes, and have all
  292. dumptypes configured with `record no', so it doesn't interfere with
  293. regular backups.
  294.  
  295.  
  296. Q: Can I backup separate disks of the same host in different
  297. configurations?
  298.  
  299. A: Yes, but you have to be careful.  Amanda uses UDP to issue estimate
  300. and backup requests and, although replies to backup requests are
  301. immediate (so that TCP connections for the actual backup can be
  302. established), replies to estimate requests are not and, while one
  303. request is being processed, any other request is ignored.  The effect
  304. is two-fold: (i) if another configuration requests for estimates, the
  305. request will be ignored, and the requester will end up timing out;
  306. (ii) if another configuration has already finished the estimates, and
  307. is now requesting for backups, the backup requests will time-out.
  308.  
  309.   So, there are two easy ways out: (i) ensure that the configurations
  310. never run concurrently, or (ii) set up two different installations of
  311. the Amanda server, using different services names to contact the
  312. clients, i.e., different port numbers.  This can be attained with the
  313. configure flag --with-testing=<service-suffix>.  Yes, the flag name is
  314. not appropriate, but so what?
  315.  
  316.    If you don't want to set up two installations of Amanda (I agree,
  317. it's overkill), but you still want to back up disks of the same host
  318. in separate configurations, you can set up Amanda so that one
  319. configuration only starts after the first one has already finished its 
  320. One possible way to work-around this limitation is to start one
  321. configuration only after you know the estimates for the first one have 
  322. already finished (modifying the crontab entries, according to history
  323. data).  You'll also have to delay the starttime (a dumptype option) of 
  324. the disks in the first configuration, so that they don't start backing 
  325. up before the estimates of the second configuration finish.
  326.  
  327.  
  328. Q: Can Amanda span large filesystems across multiple tapes?
  329.  
  330. A: Not yet :-(
  331.  
  332.    This is an open project, looking for developers.  If you'd like to
  333. help, please take a look at the Amanda Ongoing Projects Page, where
  334. more up-to-date information is likely to be found about this project.
  335.  
  336.    The current work-around is to use GNU tar to back up subdirectories
  337. of the huge filesystem separately.  But be aware of the problems
  338. listed in the next question:
  339.  
  340.  
  341. Q: What's the difference between option `skip-full' and `strategy nofull'?
  342.  
  343. A: `strategy nofull' is supposed to handle the following situation:
  344. you run a full dump off-line once a millenium :-), because that disk
  345. isn't supposed to change at all and, if it does, changes are minimal.
  346. Amanda will run only level 1 backups of that filesystem, to avoid the
  347. risk of overwriting a level 1 backup needed to do a restore.
  348. Remember, you run full dumps once a millenium, and your tape cycle
  349. probably won't last that long :-)
  350.  
  351.    `skip-full', OTOH, is supposed to let the user run full dumps
  352. off-line regularly (i.e., as often as specified in the dumpcycle),
  353. while Amanda takes care of the incrementals.  Currently, Amanda will
  354. tell you when you're supposed to run the level 0 backups but, if you
  355. fail to do so, Amanda will not only skip a full day's worth of
  356. valuable backups of the filesystem, on the day it told you to the full
  357. backup manually, but it will also run a level 1 backup on the next
  358. day, even if you have not performed the full backup yet.  Worse yet:
  359. it might perform a level 2 on the next day, just after you have run
  360. the level 0, so, if the disk should crash, you'd have to restore a
  361. level 0 then a level 2, but not the level 1!  Not a real problem, but
  362. definitely strange, eh?
  363.  
  364.  
  365. Q: Why does `amdump' report `results missing'?
  366.  
  367. A: One of the possible reasons is that you have requested too many
  368. backups of the host.  In this case, the estimate request or the reply
  369. may not fit in a UDP packet.  This will cause Amanda not to perform
  370. some of the backups.  Fixing this problem involves modifying the way
  371. estimate requests are issued, so that no packet exceeds the maximum
  372. packet size, and issuing additional requests that did not fit in a UDP
  373. packet after a reply for the previous set is obtained.
  374.  
  375.    One possible work-around is to try to shorten the pathnames of the
  376. directories and the exclude file names, so that more requests fit in
  377. the UDP packet.  You may create short-named links in some directory
  378. closer to the root (/) so as to reduce the length of names.  I.e.,
  379. instead of backing up /usr/home/foo and /usr/home/bar, create the
  380. following links:
  381.     /.foo -> /usr/home/foo
  382.     /.bar -> /usr/home/bar
  383. then list /.foo and /.bar in the disklist.
  384.  
  385.    Another approach is to group sub-directories in backup sets,
  386. instead of backing up them all separately.  For example, create
  387. /usr/home/.bkp1 and move `foo' and `bar' into it, then create links so
  388. that the original pathnames remain functional.  Then, list
  389. /usr/home/.bkp1 in the disklist.  You may create as many `.bkp<N>'
  390. directories as you need.
  391.  
  392.    A simpler approach, that may work for you, is to backup only a
  393. subset of the subdirectories of a filesystem separately.  The others
  394. can be backed up together with the root of the filesystem, using an
  395. exclude list that prevents duplicate backups.
  396.  
  397.  
  398. Q: Why does `amdump' report `disk offline'?
  399.  
  400. A: Well, assuming the disk is not really off line :-), it may be a
  401. permission problem, but then, `amcheck' would have reported it.
  402.  
  403.    Another possible reason for this failure is a filesystem error,
  404. that causes DUMP to crash before it estimates the backup size; a
  405. `fsck' may help.
  406.  
  407.    Yet another possibility is that the filesystem is so large that the
  408. backup program is incorrectly reporting the estimated size, for
  409. example, by printing a negative value that Amanda will not accept as a
  410. valid estimate.  If you are using DUMP, contact your vendor and
  411. request a patch for dump that fixes this bug.  If you are using GNU
  412. tar, make sure it is release 1.12 or newer; 1.11.8 won't do!  Even
  413. release 1.12 may require a patch to correctly report estimates and
  414. dump sizes; check the patches directory of the Amanda distribution.
  415.  
  416.  
  417. Q: What if `amdump' reports `dumps way too big, must skip incremental
  418. dumps'?
  419.  
  420. A: It means Amanda couldn't back up some disk because it wouldn't fit
  421. in the tape(s) you have configured Amanda to use.  It considered
  422. performing some incrementals instead of full dumps, so that all disks
  423. would fit, but this wouldn't be enough, so the disk really had to be
  424. dropped in this run.
  425.  
  426.    In general, you can just ignore this message if it happens only
  427. once in a while.  Low-priority disks are discarded first, so you'll
  428. hardly miss really important data.
  429.  
  430.    One real work-around is to configure Amanda to use more tapes:
  431. increase `runtapes' in `amanda.conf'.  Even if you don't have a real
  432. tape changer, you can act yourself as a changer (`chg-manual'; more
  433. details in the question about tape changer configuration), or use
  434. `chg-multi' with a single tape unit, and lie to Amanda that it will
  435. have two tapes to use.  If you have a holding disk as large as a tape,
  436. and configure Amanda (2.4.1b1 or newer) not to reserve any space for
  437. degraded dumps, dumps that would be stored in the second tape of a run
  438. will be performed to the holding disk, so you can flush them to tape
  439. in the morning.
  440.  
  441.  
  442. Q: `amdump' reported `infofile update failed'.  What should I do?
  443.  
  444. A: Make sure all directories and files are readable and writable by
  445. the Amanda user, within the directory you specified as `infofile' in
  446. `amanda.conf'.  From then on, only run amanda server commands
  447. (amadmin, amdump, amflush, amcleanup) as the Amanda user, not as root.
  448.  
  449.  
  450. Q: Why does `amrecover' report `no index records' or `disk not found'?
  451.  
  452. A: The most common cause of this problem is not having enabled index
  453. generation in amanda.conf.  The `index yes' option must be present in
  454. every dumptype for whose disks indexes should be generated.
  455.  
  456.    Another possibility is that `amrecover' is not selecting the
  457. configuration name that contains the backups for the selected disk.
  458. You may specify a configuration name with the `-c' switch, when you
  459. invoke `amrecover'.  The default configuration name can only be
  460. specified at Amanda configure time (--with-config=<name>).
  461.  
  462.    Indexes are currently generated at backup-time only, so, if a
  463. backup was performed without creating an index, you won't be able to
  464. use `amrecover' to restore it, you'll have to use `amrestore'.
  465.  
  466.  
  467. Q: Ok, I'm done with testing Amanda, now I want to put it in
  468. production.  How can I reset its databases so as to start from
  469. scratch?
  470.  
  471. A: First, remove the `curinfo' database.  By default, it is a
  472. directory, but, if you have selected any other database format (don't,
  473. they're deprecated), they may be files with extensions such as .dir
  474. and .pag.
  475.  
  476.    Then, remove any log files from the log directory:
  477. log.<TIMESTAMP>.<count> and amdump.<count>.  Finally, remove the
  478. tapelist file, stored in the directory that contains amanda.conf,
  479. unless amanda.conf specifies otherwise.  Depending on the tape changer
  480. you have selected, you may also want to reset its state file.
  481.